1. Field of the Invention
The invention is related to the field of communication networks and, in particular, to systems and methods for maintaining registrations of communication devices within an IP Multimedia Subsystem (IMS) network.
2. Statement of the Problem
The Session Initiation Protocol (SIP) is an application-layer control protocol for creating, modifying, and terminating sessions with one or more users. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations create sessions that allow the users to agree on a set of compatible media types based on session descriptions configurable within the protocol. When a user desires a session with another user in a SIP based network, such as the IMS, the network discovers the host where the destination user may be reached. This discovery process is often performed by SIP network elements such as proxy servers and redirect servers. These network elements receive requests from originating users, locate destination users, and forward the requests to establish links between the users.
Before the links between users can be established, the users register with the network. The registrations create “bindings” in a location service for a particular domain that associates an address-of-record uniform resource identifier (URI) with one or more contact addresses. When a network element for the domain receives a request with a Request-URI that matches an address-of-record, the network element forwards the request to the contact addresses registered to that address-of-record.
Registration is performed by users sending a REGISTER request to a user agent server (UAS) known as a registrar. In IMS, this function may be performed by a home subscriber server (HSS). The REGISTER request adds, removes, and/or queries bindings. For example, a REGISTER request from a user may add a new binding between an address-of-record and one or more contact addresses. A REGISTER request may also remove previous bindings upon expiration or query bindings to determine which bindings are currently in place for an address-of-record.
The REGISTER request also establishes a time limit for the registration. For example, the REGISTER includes an “expires” header field that is used to establish a desired duration for registration of the user's device with the network. If no expires header parameter is provided in the “contact SIP header” and no “expires SIP header” exists, the network establishes a default expiration for the bindings at 3600 seconds, unless updated, or “refreshed”. Once a binding expires for a present address of record, the user is no longer able to receive incoming calls from the network at its present contact address.
Each device is responsible for refreshing the bindings that it has previously established. A device should not refresh bindings set up by other devices. The 200 (OK) response from the registrar contains a list of contact fields enumerating all current bindings. The device compares each contact address to see if it created the contact address, using comparison rules (see e.g., section 19.1.4 of RFC 3261). If so, the device updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The device then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It may combine several updates into one REGISTER request.
A problem exists with the present REGISTER request when it is used to update the expiration time interval due to the number of REGISTER requests being processed. A network may have hundreds of thousands of devices registered at any given time. Thus, a network element may be continuously bombarded with REGISTER requests that are used to merely refresh an already registered device. These requests may cost the network element precious clock cycles that could be better used processing other message traffic.